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Usage of the RSVP ASSOCIATION Object 
Abstract 


The Resource Reservation Protocol (RSVP) ASSOCIATION object is 
defined in the context of GMPLS-controlled label switched paths 
(LSPs). In this context, the object is used to associate recovery 
LSPs with the LSP they are protecting. This document reviews how the 
association is to be provided in the context of GMPLS recovery. No 
new procedures or mechanisms are defined by this document, and it is 
strictly informative in nature. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any 
errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6689. 
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1. Introduction 


End-to-end and segment recovery are defined for GMPLS-controlled 
label switched paths (LSPs) in [RFC4872] and [RFC4873], respectively. 
Both definitions use the ASSOCIATION object to associate recovery 
LSPs with the LSP they are protecting. This document provides 
additional narrative on how such associations are to be identified. 
This document does not define any new procedures or mechanisms and is 
strictly informative in nature. 


It may not be immediately obvious to the informed reader why this 
document is necessary; however, questions were repeatedly raised in 
the Common Control and Measurement Plane (CCAMP) working group on the 
proper interpretation of the ASSOCIATION object in the context of 
end-to-end and segment recovery, and the working group agreed that 
this document should be produced in order to close the matter. This 
document formalizes the explanation provided in an e-mail to the 
working group authored by Adrian Farrel, see [AF-EMAIL]. This 
document in no way modifies the normative definitions of end-to-end 
and segment recovery, see [RFC4872] or [RFC4873]. 


2. Background 


This section reviews the definition of LSP association in the 
contexts of end-to-end and segment recovery as defined in [RFC4872] 
and [RFC4873]. This section merely reiterates what has been defined; 
if differences exist between this text and [RFC4872] or [RFC4873], 
the earlier RFCs provide the authoritative text. 
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2.1. LSP Association 


[RFC4872] introduces the concept and mechanisms to support the 
association of one LSP to another LSP across different RSVP - Traffic 
Engineering (RSVP-TE) sessions. Such association is enabled via the 
introduction of the ASSOCIATION object. The ASSOCIATION object is 
defined in Section 16 of [RFC4872]. It is explicitly defined as 
having both general application and specific use within the context 
of recovery. End-to-end recovery usage is defined in [RFC4872] and 
is covered in Section 2.2 of this document. Segment recovery usage 
is defined in [RFC4873] and is covered in Section 2.3 of this 
document. Resource sharing type LSP association is also defined in 
[RFC4873]. While strictly speaking, such association is beyond the 
scope of this document, it is covered in Section 2.4 of this document 
for completeness. The remainder of this section covers generic usage 
of the ASSOCIATION object. 


In general, LSP association using the ASSOCIATION object can take 
place based on the values carried in the ASSOCIATION object. This 
means that association between LSPs can take place independently of 
and across different sessions. This is a significant enhancement 
from the association of LSPs that is possible in base MPLS [RFC3209] 
and GMPLS [RFC3473]. 


When using the ASSOCIATION object, LSP association is always 
initiated by an upstream node that inserts appropriate ASSOCIATION 
objects in the Path message of LSPs that are to be associated. 
Downstream nodes then correlate LSPs based on received ASSOCIATION 
objects. Multiple types of LSP association are supported by the 
ASSOCIATION object, and downstream correlation is made based on the 


type. 


[RFC4872] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION 
object. Both objects have essentially the same semantics, only 
differing in the type of address carried (IPv4 and IPv6). The 
defined objects carry multiple fields. The fields, taken together, 
enable the identification of which LSPs are in association with one 
another. The [RFC4872]-defined fields are: 


o Association Type: 
This field identifies the usage, or application, of the 
ASSOCIATION object. The currently defined values are 
"Recovery" [RFC4872] and "Resource Sharing" [RFC4873]. This 
field also scopes the interpretation of the object. In other 
words, the type field is included when matching LSPs (i.e., the 
type fields must match), and the way associations are 
identified may be type dependent. 
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o Association Source: 
This field is used to provide global scope (within the address 
space) to the identified association. There are no specific 
rules in the general case for which an address should be used 
by a node creating an ASSOCIATION object beyond that the 
address is "associated to the node that originated the 
association", see [RFC4872]. 


o Association ID: 
This field provides an "identifier" that further scopes an 
association. Again, this field is combined with the other 
ASSOCIATION object fields to support identification of 
associated LSPs. The generic definition does not provide any 
specific rules on how matching is to be done, so such rules are 
governed by the Association Type. Note that the definition 
permits the association of an arbitrary number of LSPs. 


As defined, the ASSOCIATION object may only be carried in a Path 
message, so LSP association takes place based on the Path state. The 
definition permits one or more objects to be present. The support 
for multiple objects enables an LSP to be associated with other LSPs 
in more than one way at a time. For example, an LSP may carry one 
ASSOCIATION object to associate the LSP with another LSP for 
end-to-end recovery, and at the same time carry a second ASSOCIATION 
object to associate the LSP with another LSP for segment recovery, 
and at the same time carry a third ASSOCIATION object to associate 
the LSP with yet another LSP for resource sharing. 


2.2. End-to-End Recovery LSP Association 


The association of LSPs in support of end-to-end LSP recovery is 
defined in Section 16.2 of [RFC4872]. There are also several 
additional related conformance statements (i.e., use of [RFC2119] 
defined key words) in Sections 7.3, 8.3, 9.3, and 11.1 of [RFC4872]. 
When analyzing the definition, as with any Standards Track RFC, it is 
critical to note and differentiate which statements are made using 
[RFC2119] defined key words, which relate to conformance, and which 
statements are made without such key words, and are thereby only 
informative in nature. 


As defined in Section 16.2, end-to-end recovery-related LSP 
association may take place in two distinct forms: 


a. Between multiple (one or more) working LSPs and a single shared 
(associated) recovery LSP. This form essentially matches the 
shared 1:N (N >= 1) recovery type described in the other 
sections of [RFC4872]. 
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b. Between a single working LSP and multiple (one or more) 
recovery LSPs. This form essentially matches all other 
recovery types described in [RFC4872]. 


Both forms share the same Association Type (Recovery) and the same 
Association Source (the working LSP’s tunnel sender address). They 
also share the same definition of the Association ID, which is 
(quoting [RFC4872]): 


The Association ID MUST be set to the LSP ID of the LSP being 
protected by this LSP or the LSP protecting this LSP. If unknown, 
this value is set to its own signaled LSP_ID value (default). 
Also, the value of the Association ID MAY change during the 
lifetime of the LSP. 


The interpretation of the above is fairly straightforward. The 
Association ID carries one of three values: 
- The LSP ID of the LSP being protected. 
- The LSP ID of the protection LSP. 
- In the case where the matching LSP is not yet known (i.e., 
initiated), the LSP ID value of the LSP itself. 


The text also explicitly allows for changing the Association ID 
during the lifetime of an LSP. However, this is only an option, and 
is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). 
It should be noted that [RFC4872] does not describe when such a 
change should be initiated or the procedures for executing such a 
change. Clearly, care needs to be taken when changing the 
Association ID to ensure that the old association is not lost during 
the transition to a new association. 


The text does not preclude, and it is therefore assumed, that one or 
more ASSOCIATION objects may also be added to an LSP that was 
originated without any ASSOCIATION objects. Again, this is a case 
that is not explicitly discussed in [RFC4872]. 


From the above, this means that the following combinations may occur: 


Case 1. When the ASSOCIATION object of the LSP being protected is 
initialized before the ASSOCIATION objects of any recovery 
LSPs are initialized, the Association ID in the LSP being 
protected and any recovery LSPs will carry the same value, 
and this value will be the LSP ID value of the LSP being 
protected. 
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Case 2. When the ASSOCIATION object of a recovery LSP is 
initialized before the ASSOCIATION object of any protected 
LSP is initialized, the Association ID in the recovery LSP 
and any LSPs being protected by that LSP will carry the 
same value, and this value will be the LSP ID value of the 
recovery LSP. 


Case 3. When the ASSOCIATION objects of both the LSP being 
protected and the recovery LSP are concurrently 
initialized, the value of the Association ID carried in 
the LSP being protected is the LSP ID value of the 
recovery LSP, and the value of the Association ID carried 
in the recovery LSP is the LSP ID value of the LSP being 
protected. As this case can only be applied to LSPs with 
matching tunnel sender addresses, the scope of this case 
is limited to end-to-end recovery. Note that this is 
implicit in [RFC4872], as its scope is limited to end-to- 
end recovery. 


In practical terms, Case 2 will only occur when using the shared 1:N 
(N >= 1) end-to-end recovery type, and Case 1 will occur with all 
other end-to-end recovery types. Case 3 is allowed, and it is 
subject to interpretation as to how often it will occur. Some 
believe that this will be the common case and, furthermore, that 
working and recovery LSPs will often first be initiated without any 
ASSOCIATION objects, and then Case 3 objects will be added once the 
LSPs are established. Others believe that Case 3 will rarely, if 
ever occur. Such perspectives have little impact on 
interoperability, as an [RFC4872]-compliant implementation needs to 
properly handle (identify associations for) all three cases. 


It is important to note that Section 16.2 of [RFC4872] provides no 
further requirements on how or when the Association ID value is to be 
selected. The other sections of the document do provide further 
narrative and three additional requirements. In general, the 
narrative highlights Case 3 identified above but does not preclude 
the other cases. The three additional requirements are, by [RFC4872] 
section number: 


o Section 7.3 -- "The Association ID MUST be set by default to the 
LSP ID of the protected LSP corresponding to N = 1." 


When considering this statement together with the three cases 
enumerated above, it can be seen that this statement clarifies 
which LSP ID value should be used when a single shared protection 
LSP is established simultaneously with Case 3, or after Case 2, 
and with more than one LSP to be protected. 
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o Section 8.3 -- "Secondary protecting LSPs are signaled by setting 
in the new PROTECTION object the S bit and the P bit to 1, and in 
the ASSOCIATION object, the Association ID to the associated 
primary working LSP_ID, which MUST be known before signaling of 
the secondary LSP." 


This requirement clarifies that when using the "Rerouting without 
Extra-Traffic" type of recovery, it is required to follow either 
Case 1 or 3, but not 2, as enumerated above. 


o Section 9.3 -- "Secondary protecting LSPs are signaled by setting 
in the new PROTECTION object the S bit and the P bit to 1, and in 
the ASSOCIATION object, the Association ID to the associated 
primary working LSP_ID, which MUST be known before signaling of 
the secondary LSP." 


This requirement clarifies that when using the "Shared-Mesh 
Restoration" type of recovery, it is required to follow either 
Case 1 or 3, but not 2, as enumerated above. 


o Section 11.1 -- "In both cases, the Association ID of the 
ASSOCIATION object MUST be set to the LSP ID value of the 
signaled LSP." 


This requirement clarifies that when using the "LSP Rerouting" 
type of recovery, it is required to follow either Case 1 or 3, 
but not 2, as enumerated above. 


2.3. Segment Recovery LSP Association 
GMPLS segment recovery is defined in [RFC4873]. Segment recovery 
reuses the LSP association mechanisms, including the Association Type 
field value, defined in [RFC4872]. The primary text to this effect 


in [RFC4873] is: 


3.2.1. Recovery Type Processing 


Recovery type processing procedures are the same as those defined 
in [RFC4872], but processing and identification occur with respect 
to segment recovery LSPs. Note that this means that multiple 
ASSOCIATION objects of type recovery may be present on an LSP. 


This statement means that Case 2, as enumerated above, is to be 
followed; furthermore, the Association Source is set to the tunnel 
sender address of the segment recovery LSPs. The explicit exclusion 
of Case 3 is not listed, as its non-applicability is considered 
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obvious to the informed reader. (Perhaps having this exclusion 
explicitly identified would have obviated the need for this 
document.) 

2.4. Resource Sharing LSP Association 


Section 3.2.2 of [RFC4873] defines an additional type of LSP 
association that is used for "Resource Sharing". Resource sharing 
enables the sharing of resources across LSPs with different SESSION 
objects. Without this object, only sharing across LSPs with a shared 
SESSION object is possible, see [RFC3209]. 


Resource sharing is indicated using a new Association Type value. As 
the Association Type field value is not the same as what is used in 
recovery type LSP association, the semantics used for the association 
of LSPs using an ASSOCIATION object containing the new type differs 
from recovery type LSP association. 


Section 3.2.2 of [RFC4873] states the following rules for the 
construction of an ASSOCIATION object in support of resource sharing 
type LSP association: 


o The Association Type value is set to "Resource Sharing". 


o Association Source is set to the originating node’s router 
address. 


o The Association ID is set to a value that uniquely identifies 
the set of LSPs to be associated. 


The setting of the Association ID value to the working LSP’s 
LSP ID value is mentioned, but using the "MAY" key word. Per 
[RFC2119], this translates to the use of the LSP ID value as 
being completely optional and that the choice of Association ID 
is truly up to the originating node. 


Additionally, the identical ASSOCIATION object is used for all LSPs 
that should be associated using Resource Sharing. This differs from 
recovery type LSP association where it is possible for the LSPs to 
carry different Association ID fields and still be associated (see 
Case 3 in Section 2.2). 


3. Association of GMPLS Recovery LSPs 
The previous section reviews the construction of an ASSOCIATION 
object, including the selection of the value used in the Association 


ID field, as defined in [RFC4872] and [RFC4873]. This section 
reviews how a downstream receiver identifies that one LSP is 
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associated within another LSP based on ASSOCIATION objects. Note 
that this section in no way modifies the normative definitions of 
end-to-end and segment recovery, see [RFC4872] or [RFC4873]. 


As the ASSOCIATION object is only carried in Path messages, such 
identification only takes place based on Path state. In order to 
support the identification of the recovery type association between 
LSPs, a downstream receiver needs to be able to handle all three 
cases identified in Section 2.2. Cases 1 and 2 are simple, as the 
associated LSPs will carry the identical ASSOCIATION object. This is 
also always true for resource sharing type LSP association, see 
Section 2.4. Case 3 is more complicated, as it is possible for the 
LSPs to carry different Association ID fields and still be 
associated. The receiver also needs to allow for changes in the set 
of ASSOCIATION objects included in an LSP. 


Based on the [RFC4872] and [RFC4873] definitions related to the 
ASSOCIATION object, the following behavior can be followed to ensure 
that a receiver always properly identifies the association between 
LSPs: 


o Covering Cases 1 and 2 and resource sharing type LSP 
association: 


For ASSOCIATION objects with the Association Type field values 
of "Recovery" (1) and "Resource Sharing" (2), the association 
between LSPs is identified by comparing all fields of each of 
the ASSOCIATION objects carried in the Path messages associated 
with each LSP. An association is deemed to exist when the same 
values are carried in all fields of an ASSOCIATION object 
carried in each LSP’s Path message. As more than one 
association may exist (e.g., in support of different 
association types or end-to-end and segment recovery), all 
carried ASSOCIATION objects need to be examined. 


o Covering Case 3: 


Any ASSOCIATION object with the Association Type field value of 
"Recovery" (1) that does not yield an association in the prior 
comparison needs to be checked to see if a Case 3 association 
is indicated. As this case only applies to end-to-end recovery, 
the first step is to locate any other LSPs with the identical 
SESSION object fields and the identical tunnel sender address 
fields as the LSP carrying the ASSOCIATION object. If such 
LSPs exist, a case 3 association is identified by comparing the 
value of the Association ID field with the LSP ID field of the 
other LSP. If the values are identical, then an end-to-end 
recovery association exists. As this behavior only applies to 
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end-to-end recovery, this check need only be performed at the 
egress. 


No additional behavior is needed in order to support changes in the 
set of ASSOCIATION objects included in an LSP, as long as the change 
represents either a new association or a change in identifiers made 
as described in Section 2.2. 


4. Security Considerations 


This document reviews procedures defined in [RFC4872] and [RFC4873] 
and does not define any new procedures. As such, no new security 
considerations are introduced in this document. 
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